General Introduction to I2P

The aggressive market is ready to make money on everything that can be sold, but popular offers in the field of private communications are fiction and lies. This happens for simple reasons: firstly, business was invented not by philanthropists, but by selfish people; secondly, any entrepreneur, even with the best intentions, is accountable to third parties and in controversial situations always puts his own interests above the interests of the client.

Now we will talk about I2P - a non-profit singularity of network privacy and anonymity, where no one except you knows where and who is transmitting your information. The I2P network (stands for Invisible Internet Project) is an overlay decentralized peer-to-peer network. Overlay means it works on top of other networks, for example, the regular Internet; decentralized - distributed, without a single point of failure: if one node, half the network fails, or there are only 3 users left in the entire network, I2P will still function. I2P is a peer-to-peer network, since all participants have equal rights and opportunities: each user of the hidden network builds his tunnels through other participants and is himself a potential link in the chain of another user. At the same time, natural network activity does not in any way compromise the subscriber to the home provider or members of the hidden network.

If you've never encountered I2P, this article is the beginning of your journey to truly private and anonymous communication; If you're a seasoned hidden networking enthusiast, this review is sure to fill in the gaps and help organize your existing knowledge..

The difference between a traditional network and a hidden one

The traditional Internet is nothing more than an extensive network of computers. It is designed in such a way that it is not difficult to track user actions: the Internet provider has access to the history of your web surfing, whether you want it or not. It could also be a VPN provider; in any case, some third parties know about your interests. Thanks to this, the global network turns into a tool of manipulation and one-sided propaganda..

Hidden networks, the so-called “darknet”, are aimed at the opposite - complete anonymity of users.

Using a sketchy town as an example, we will depict the differences between the regular Internet and a primitive hidden network. The example is greatly simplified to form a general understanding.

Residents communicate through windows - this is an exchange of information through open channels. Please note that there is an “authorized” neighbor (house No. 2), who hears everything and, as we know, records everything. Let's draw an analogy between encrypting information and a secret language: even if the neighbors speak a language unfamiliar to the spy, at least he knows that certain houses maintain contact. In the case of regular Internet, the provider stores information about the sites you visit. He doesn’t need to know what exactly you wrote on the opposition forum. The mere fact of visiting such a resource speaks volumes. Two houses (No. 4 and No. 5) have connected underground tunnels - they exchange messages without shouting to the street. The spy does not see that these people are communicating.

An important term that will be needed later is DPI (deep packet inspection). In our illustration, this concept can be used to describe a spy’s ability to understand the secret meaning of the words he hears. For example, people will shout the word "pipe" out the window before communicating through hidden tunnels. The spy will quickly understand this and begin to scour the houses from which the code word came. This will be called DPI detection.

To imagine a hidden peer-to-peer network where all nodes have equal rights and opportunities, we make an important note: each house can only transmit a message to its nearest neighbor, asking it to forward the message further. This gives an illustration of a peer-to-peer network, in which each node simultaneously acts as a receiver, sender and transit node. Several problems are obvious: the anonymity of the sender, the safety and secrecy of data at transit nodes, as well as the presence of malicious network participants who may try to analyze messages passing through them to determine the identity of anonymous subscribers. The I2P network was originally designed with the assumption that all intermediate nodes are compromised or malicious. I2P tunnels are unidirectional, i.e. incoming traffic goes through one chain of nodes, and outgoing traffic goes through another. In addition, all transmitted network encrypted messages tend to overlap each other, merging into information noise, which makes attempts to listen and analyze the passing data stream pointless.

Basic understanding of cryptography

There are two main types of encryption algorithms: symmetric and asymmetric. This knowledge will be needed to understand the further story..

Symmetric algorithms are simpler and therefore work many times faster: they use one key to encrypt and decrypt information. The weak point of this approach is the transfer of the key from one user to another. If an attacker can intercept the key, he will gain access to sensitive information. The security factor in symmetric encryption (specifically AES, a common algorithm) is the initialization vector (IV). The initialization vector is a critical component that simulates the first block of information. Since each 16-byte block affects the next block with AES encryption, the integrity of the information is critical.

Asymmetric encryption is not subject to this threat because Each user has two keys: public and private. The public key is transmitted openly and is used to encrypt information, which can later be decrypted only with the secret key from the corresponding keychain. Asymmetric encryption is used everywhere, but is much inferior to symmetric algorithms in terms of speed. In the case where there is a lot of encryption, as in I2P, and maximum performance is needed, asymmetric key agreement algorithms are used. To put it simply: users exchange public keys that cannot be intercepted, and mathematically derive a common symmetric key from them. This is called coordination. Once agreed upon, users have fast cryptographic operations because... use a symmetric algorithm, where encryption and decryption occur with one key without additional resource-intensive calculations inherent in asymmetric encryption with public and private keys (also called public and private).

Important cryptographic operations include hash functions. Unlike encryption, they do not change the original information, and do not have keys as such.

By passing the information through a hash function, we obtain a unique string. The resulting string is called a hash sum and allows you to check the integrity of the information, because even the most insignificant change in information will produce a completely new hash sum.

A digital signature is a derivative of the combined use of asymmetric encryption algorithms and a hash function: first, a hash sum is output, and then the key identifier of the signing user is embedded in it with the secret key. Having the public key of the signatory, we independently check the hash sum of the information and compare it with the one that was originally provided by the sender. This verifies the accuracy of the information received..

General principles of I2P operation

In an I2P network, all packets are encrypted on the sender's side and decrypted only on the recipient's side, while none of the intermediate participants in the exchange are able to intercept the original data. For this reason, there is no need to worry about application programs encrypting their traffic. For example, a site on I2P does not need to use TLS encryption to prevent user input from being intercepted, as is done on the regular Internet, i.e. no need to use HTTPS protocol.

Also, none of the network participants knows who the actual sender and who the recipient are, since the status of the node from which the packet came is unknown, it can be a sender or an intermediate one, and the next one to whom this packet needs to be sent can be a recipient or such the same as an intermediate node. The intermediate node cannot find out the endpoints of the sender and recipient, just as it cannot find out what happened to the packet just transmitted to the next node: whether it processed it or passed it somewhere further.

I2P uses the concept of routers and endpoints: A router is an impersonal network participant: neither a client nor a server - just a transit node no different from others. By establishing a direct connection with each other, routers see each other's real IP addresses, but this information does not indicate anything other than the likely use of the I2P network by the subscriber at the other end. If an attacker decides to identify all network participants, he will stumble upon various errors such as proxy servers, and in any case will not have actual data about any intranetwork activity of the identified users. By installing the I2P network client on your device, you are actually installing an I2P router - an impersonal link in the network.

An endpoint, on the other hand, is a meaningful entity—either a server or a client—but its actual location is unknown. I2P network endpoint addresses use identifiers derived from the public signature key: the hash sum gives a unique fixed-length string, at the end of which the pseudo-domain zone “.b32.i2p” is inserted for readability - this is how the usual intranet address is obtained. To use human-readable domains in the “.i2p” zone, for example acetone.i2p, there are free registrars that are quite simple to use. The domain is linked to the full address.

The endpoint is created by the router administrator, while the router continues its “grey” work without informing anyone about the addresses located on it. The router, receiving information that is intended for a local resource, does not transmit it further, but none of the network participants can recognize this: the receiving router behaves in the same way as a regular transit node.

Transit nodes are part of a chain of servers that form a tunnel. A tunnel can be thought of as a pipe passing through several rooms: water enters at one end and exits at the other, while observers in the intermediate rooms see the pipe, can hear the noise of the flow inside, but do not know what exactly is flowing through it. In I2P, all routers by default can take part in building other people's tunnels, but no one knows what, where and to whom is transmitted through these tunnels. By creating a destination, the user himself determines the length of incoming and outgoing tunnels, as well as their number. This information remains known only to the tunnel creator: intermediate links know nothing about other transit nodes and their total number.

In the illustration, the empty circles are routers. Only in our diagram these circles are located next to each other, but in fact these are computers all over the globe. The user's outgoing tunnels are indicated in brown, and the user's incoming tunnels are indicated in blue. The owner of the output tunnel knows nothing about the destination's incoming tunnel except the end through which it sends information to the requested resource.

By default, the length of the tunnels is 3 nodes, but depending on the user’s needs, it can be 1 transit node or as many as 8, or even 0, then there will be a direct connection to the second party’s tunnel. As you can see, the end resource administrator has an input tunnel of 4 nodes. Having received a request, the web resource sends a response to the user's input tunnel through its output tunnel, i.e. on a completely different path. Looking at the diagram, you can imagine how difficult it is for the user to determine the real location of the interlocutor. Considering that every 10 minutes the existing tunnel is replaced with a new one with new digital signatures and encryption keys, de-anonymizing someone seems like a fantasy.

An important essence of the I2P network is floodfills: special routers that collect information about the network and exchange it with each other. Anyone can become a floodfillr by setting the appropriate parameter in the router configuration file. All server endpoints of the network (i.e., points to which a connection is expected) automatically publish information about themselves on floodfills, which is collectively called a LeaseSet.

Lizset will include the full endpoint address, encryption keys, and a list of incoming tunnels. When you access any address in I2P, you automatically ask a random floodfill for the LeaseSet of that address. If the floodfil does not know the requested address, it reports the addresses of other floodfils and the search continues. Floodfil is a router (not an endpoint) and accepts connections directly, i.e. does not have its own entrance tunnels. However, endpoints access it exclusively through anonymous chains, thereby hiding the location of published resources and those who want to access them.

Since each endpoint has an average of three input tunnels, which change every 10 minutes, access to floodfills occurs like an avalanche, albeit with a small data flow. Thanks to this, there is always a chaotic movement of service information in the network, forming “white noise”».

In addition to searching for LeaseSets, white noise is generated by network probing: each router polls a random floodfill at short intervals, receiving three new routers in response (thus increasing its own network pattern and finding new floodfills). The main source of network noise on a router is transit traffic: it creates a lot of network activity regardless of the endpoints located on the router. Also, being a transit link, the router adds a payload to the traffic of other people’s tunnels - the traffic of its hidden services. The more transit traffic on a router, the more absolute the secrecy of its endpoints: any actions on a hidden resource, even a DDoS attack, cannot be compared with the network activity of a particular server. An active network node has an average of 5,000 active routers in its database and receives hundreds, or even thousands, of completely random transit connections. As they say: try to analyze.

Separately, we note the mechanism for selecting a floodfill by the user. This is an important issue that was given due consideration during development. Since any of the floodfills can be contained by a malicious user, the task was to make his attempts at analysis and other dishonest actions not applicable to a specific person. The floodfill for a request is selected as follows: the target address and today's date are taken. From this information, a SHA256 hash is derived, resulting in data of the same length as a regular address. Then a floodfill is searched in the router’s local database: the one that gives the smallest number during the “EXCLUSIVE OR” operation with the “target address + date” block is used. This approach makes the host selection for service requests unpredictable and changing daily for each address. Within this material, “accidental floodfiling” is mentioned, but be aware of what lies behind these words.

We recently mentioned DPI - the study of network packets in order to identify the type of information being transmitted. It was mentioned for a reason, because you should know about this technology, and also that all I2P traffic is resilient before analysis. Network traffic is encrypted from the very bottom, starting with transport protocols. I2P uses: NTCP2, as a crypto analogue of TCP, and S.S.U., as a crypto-analogue of UDP. An I2P router accepts network traffic from application programs accessing a hidden network and wraps the usual protocols in their encrypted counterparts. After processing, it is impossible to identify anything intelligible in network packets, because everything is encrypted, including headers and size. The size of the packets is hidden by padding, i.e. filling packets with random data to a certain size. Information about the real size of the network packet is transmitted in encrypted form. When decrypted on the end device, the mixed “garbage” is simply discarded. Thus, the “white noise” of the network, i.e. information that is practically meaningless to a person is mixed with user information and from the outside is absolutely indistinguishable from it.

The described network organization eliminates the need to use IP addresses in intranet routing and allows all resources to remain anonymous, since no one knows what is located on a particular router: whether it is just an output proxy of an ordinary user or a global web resource.

Complementing and reinforcing everything that has been said, we will describe in detail the process from the first launch of the router to the opening of a web page. When first launched, the router does not have any data about the network, so it contacts a random resid server, which gives the user its database of known routers. Resides are kept by enthusiasts, their list is freely available. In fact, the information from the resid is a zip archive of the netDb folder, in which each router stores information about the network. Since data transfer occurs via the regular Internet, in order to avoid substitution along the way, the archives are signed with a digital key. The public keys of all current resids are contained in the I2P router itself. If for some reason we do not want to contact public resid servers, we can use existing network databases, for example, from our other routers. The resid is not contacted if there are at least 25 routers in the netDb folder. After connecting to several current participants, automatic continuous expansion of the network picture begins.

Construction of tunnels

To create tunnels that provide a comprehensive level of privacy, I2P uses what is called “garlic encryption.” “Garlic” I2P represents a block of information that includes several “garlics” of 528 bytes each. The “garlics” are laid in a random order, so their sequence does not carry any information. Each recipient of the garlic clove identifies its clove by the first 16 bytes, which are part of the hash of its address. Once the desired “garlic clove” is found, the instructions it contains are decrypted by the router key.

According to the instructions, all the garlic can be transferred to the next node, where the procedure will be repeated. When building an outgoing tunnel, the instructions for the last recipient are to inform the tunnel creator that the chain has been completed. Since all tunnels are unidirectional, the entrance tunnel is communicated to it. The first outgoing tunnels are created with the response returning to a tunnel of zero length, i.e. directly to the creator, however, this is a rare phenomenon and the fact that the tunnel has zero length is known exclusively to its creator, so the user is not compromised.

When creating an incoming tunnel, the picture is even more elegant: through the outgoing tunnel, garlic is transferred to a random router, the last recipient of which is the creator himself. From the position of the last transit link, the transfer of “garlic” to the tunnel creator is perceived as a transfer to the next transit node. This is why transit nodes cannot know the length of the tunnels and their owners.

When building a tunnel with a length of no more than 4 participants, i2pd forms a “garlic” of 4 cloves, in other cases a “garlic” of 8 parts is formed. Empty garlic cloves are filled with random information and are indistinguishable from real ones.

The I2P protocol does not allow tunnels longer than 8 participants, but in practice 4 transit nodes are considered a comprehensive solution.

The “garlic” contains information for each participant:

1. Tunnel number on his router (random 4 bytes).

2. The address of the next router and the tunnel number on it (almost like the IP address and port number on a regular network).

3. Symmetric encryption key and initialization vector (IV) encryption key. The initialization vector itself is contained at the beginning of the message.

4. Role of the node in the chain: final or intermediate.

5. Symmetric encryption key and initialization vector for the response. They encrypt the status of the transit router: is it ready to accept a new tunnel. If at the end it turns out that at least one router disagrees, the tunnel will not be created and the entire creation process will start from scratch.

Depending on the type of tunnel (incoming or outgoing), the last link takes on the role of either “Endpoint” or “Gateway”. Between participants in the same tunnel, encrypted information is transmitted in blocks of 1 kilobyte - this is the current protocol standard. The task of the last outgoing node is to collect information into a more significant packet and send it to the desired user on his incoming tunnel. The operation of an incoming tunnel router is the opposite: it divides the received information into blocks and sends it to the other end of the tunnel. Each tunnel lasts 10 minutes. To avoid connection breakdown, the parties create new tunnels in advance and exchange their LeaseSets. Read more about the tunnel in a separate article. material.

Interaction model

By default, i2pd provides SOCKS and HTTP proxies for applications. A proxy is an intermediary. In our case, it is an intermediary for accessing a hidden network. By default, SOCKS5 is available at 127.0.0.1:4447, the HTTP proxy is on port 4444. To open a web page hosted on an I2P network, you need to set the appropriate settings in your browser. In Firefox, the proxy is conveniently configured through the network configuration, or through the FoxyProxy plugin. When we entered the site address in the configured browser, the I2P router received our request and began working.

First, a random floodfill is contacted with a request for the LeaseSet of the desired destination. The user's egress proxy is the endpoint, i.e. hidden essence. In order not to reveal its location, the floodfill is accessed through a chain of transit nodes. We also provide it with our input tunnel details for a response. Let's say that the floodfill does not know the desired address, so instead of a LeaseSet, it returns three random floodfills from its database. From the new floodfills received, one is randomly selected, to which the router repeats the previous request. In our example, the second floodfill gives the necessary LeaseSet: all the necessary information to communicate with the endpoint, which includes information about input tunnels and keys. As a rule, there are at least three entrance tunnels. Having selected a random recipient input tunnel, the router sends a request to the server through it. If everything went well and the request was received, the server sends us a web page. On a normal network this happens along the same path where the request came from, but on I2P things are completely different. The local proxy endpoint sends its response LeaseSet along with our request. Having reached the server, we informed it of the address for the response: in order for the web page to open in the browser, the server needs to use its outgoing tunnel send response to our incoming. Having accepted the response through the incoming tunnel, our router processes the information and the treasured page opens in our browser!

User information, passing through the tunnels, is subject to “onion”, i.e. multilayer encryption. Before sending a message to the outgoing tunnel, the router sequentially wraps it in several layers of encryption, using the keys that were issued to the transit nodes of the tunnel. Each node of the outgoing tunnel, receiving information with the initially issued key, removes one layer of encryption and transmits the information further. The last node in the outgoing chain, Endpoint, removes the last layer of onion encryption and forwards the information to the incoming tunnel. In the incoming tunnel, onion encryption occurs in a mirror way: Gateway encrypts the information with its key, which was given to it by the creator of the tunnel, and transmits it further. Each subsequent input tunnel node adds its own encryption layer. The creator of the incoming tunnel, upon receiving information, removes all layers of onion encryption with the keys that were issued to the transit nodes. User information is end-to-end encrypted using the destination's public key, so no transit node has any sensitive information, and the final recipient, having removed all onion encryption, decrypts the information with its asymmetric key and verifies the signature.

If someone tries to break into the tunnel and slip in their information, posing as the real sender, the signature will be incorrect and the information will be rejected. After establishing a session, to optimize performance, endpoints use a set of one-time symmetric keys and tags for them, applying the appropriate keys and exchanging only tags with each other.

Read more about tunnels in a separate article. article.

Practical use

The scope of I2P is vast and is not limited to websites. You can host any web resources in I2P: forums, message boards, Git repositories, blogs and personal one-page sites. It is quite possible to organize even network turn-based games that do not require low latency in packet transmission, for example, chess or cards. I2P can also be used in building output tunnels from an unspecified location to the global network, to complete the picture by placing output proxies on anonymously paid servers. By organizing SSH access to a rental machine via I2P, you only need to log into the server once via other networks to install i2pd and configure a tunnel that will accept connections. The only limitation to fantasies is the speed of data transfer within the network. It should be noted that from year to year the speed is becoming closer to the usual indicators of the regular Internet due to optimization of the program code and a general increase in the number of nodes.

Protocol development

All this is interesting, but a logical question arises: who is behind this? Judging by the complexity of the protocol, you might think that, as in the case of the Tor network, this is something connected with intelligence services and government funding, but no. I2P is a completely free project, born and supported by enthusiasts to this day. The development of I2P in the Java programming language was started by a certain JRANDOM. The first release took place in 2003. A few years later, JRANDOM withdrew from development without leaving any news of himself, and his place was taken by a user with the nickname zzz - an American, presumably from the New York area, who at the time of publication of the article is still overseeing the development. So 10 years passed: the community grew, the I2P router was written as best they could, and official documentation was also written at this time. When searching for “I2P”, the first link usually takes us to the site geti2p.net — the official page of that same I2P router in Java. But the story doesn't end there.

In 2013, a Russian-speaking user orignal with a French nickname, apparently a big fan of pirated literature, discovered a message in the Flibusta online library about the unavailability of downloading books through the clearnet, i.e. regular internet. Users were encouraged to use I2P instead. However, Orignal, as he says, did not find an existing normal implementation of the protocol, but only a certain Java product. Despite the fact that the development of “this product” had already been going on for ten years, orignal, as a sophisticated programmer, did not appreciate it. At that time, there were a dozen more attempts on the Internet to write an i2p router in C and C++, in which absolutely nothing had been done. There was something in the product called “i2pcpp”, but it was also far from anything useful. And what does orignal do: in three months he wrote a working program in C++ suitable for downloading books from Flibusta, and he already wanted to stop there. It was July 2013. However, a certain person persuaded him to present his experience in article on Habré. The fact is that orignal had to delve into the jungle of Java code, because... The official documentation turned out to be incomplete and had a fragmented structure. After the publication of the first article, something happened: probably noticing public interest, and feeling some of the excitement inherent in all programmers, writers and composers, orignal set about writing a full-fledged network client. The debut release 0.1.0 took place on October 17, 2014. To implement it, orignal had to independently implement several cryptographic functions in C++ (which, with the expansion of the OpenSSL library, were later replaced by library ones). The new client is called i2pd - Invisible Internet Protocol Daemon. After the first release, enthusiasts joined orignal and also began working on improving the new I2P router. The developer community is named PurpleI2P.

In the first years, the i2pd initiative was met with a lot of skepticism from outside observers: in PurpleI2P they were looking for the hand of the Kremlin, bookmarks from the FSB, traces of masons and reptilians. The very name Purple, at the apogee of the drug addiction, was reduced by some individuals to the flag of the Russian Federation: mixing red, blue and white gives that same purple. However, orignal, the lead developer of i2pd, explained that the name PurpleI2P does not contain a great secret: the name was coined after a mug of English ale with an eye to the royal crown of the British Empire. This can probably be considered a reference to i2pd’s leadership over the original Java client.

Orignal continues to publish Russian-language articles about I2P to this day, telling the general public about the development of the protocol. New nicknames appear in the team of enthusiastic programmers, while others, on the contrary, go permanently offline. Most development planning takes place on IRC, on the ILITA network. The Russian-speaking community is quite active and everything is actually discussed on IRC: from new features in I2Pd to climate in Africa and new memes.

Each version of the router is replaced by the next, the community lives on, the developers are constantly coding something. So that there are no questions about what is changing, if everything is working well, let’s briefly talk about the development of the protocol: you never know that paranoids will decide that the protocol is not changing, and only the backdoor from the security forces is being honed. At the beginning of the journey, the Java router and C++ router branches did not develop synchronously, and coordination of nuances with the neighboring camp occurred with some delay. Now developers, despite differences in views, are working together to implement meaningful solutions. The most noticeable change in recent years: the transition from the NTCP transport protocol to NTCP2. This protocol is an adapted crypto-analogue of the usual TCP and is used everywhere: from opening a web page to downloading a torrent. The main difference between the two protocols is the use of an encryption algorithm: the old NTCP uses Diffie-Hellman, which is very slow and greedy for system resources, while NTCP2 uses an elliptic curve algorithm - a trend in the field of high-speed cryptosystems, superior in cryptographic strength and performance to its predecessor. This change made I2P routers more lightweight and fully usable on small devices like single board computers and smartphones (at least i2pd for sure). The replacement of the Diffie-Hellman key agreement algorithm with new solutions occurs in other parts of the protocol. For viewers who understand cryptography, we especially note that the I2P network is gradually moving to cryptographic protocols of the Noise family, which is also a good solution for performance, anonymity and reliability. I2P routers, like all programs in the world, are subject to shortcomings such as bugs and defective implementation of some functions, which entails further development, corrections, and new releases. If you are interested in details, more detailed information can be found through a search engine and in community chats.

Why is it worth using i2pd in C++ instead of a router in Java? The answer is simple: because i2pd is architecturally superior to the Java version. I2P is a treasure trove of various cryptography, the implementation of which in Java would be terribly slow. Therefore, the Java router uses libraries written in the C language. And everything would be fine, but each call to these libraries is a large overhead. And no matter how hard the developers try, there are still brakes. Not as big as they could be, but they are very far from the speed of native (i.e. built-in) cryptography from i2pd. Also, all traffic of a Java router locally passes through the actually unnecessary I2CP protocol, which, without going into details, greatly spoils the quality of work, while in i2pd this protocol exists solely for compatibility with applications on Java routers. For inquiring minds, we can say in more detail: the main problem with I2CP is that through it TCP sessions (called streams) cannot control access to tunnels and LeaseSets. I2CP also deprives Java router users of normal support for UDP tunnels: their support is provided by a separate streamr application. As a seasoned viewer already knows, the UDP protocol is used for fast streaming of data, for example, the voice of the interlocutor during an online call. It is difficult to overestimate the quality support for this protocol. In I2Pd, UDP tunnels are supported without any problems and additional software layers.

In addition to faster i2pd operation, this router also consumes less system resources compared to the Java version, because a C++ program directly interacts with the system, unlike Java, where everything runs inside a virtual machine - an additional layer between the operating system and the software. There is only more to come: while exploring the vastness of intranet sites, you will more than once come across descriptions of various problems with the performance of the I2P network, where the source of the problems will not be the protocol, but its crooked implementation in a popular client. In tests with high-speed servers and a network that completely eliminated the presence of Java routers, we managed to achieve a speed of just under a megabit per second. Today, such an indicator against the backdrop of an average of several tens of kilobits seems incredible! IN video, Based on the text of which this article was compiled, a screenshot of recent correspondence between two leading developers is given: orignal and zzz. While video streams are being streamed through i2pd in test mode, the Java router does not even allow you to listen to online radio. To increase the average speed of an I2P network you need: firstly, everyone needs to keep their node turned on for the maximum available time, and secondly, it must be a network node running on i2pd.

Comparison with other networks

If you have an idea about the Tor network and mesh networks like Yggdrasil Network, After everything has been said about I2P, it doesn’t make much sense to say how they differ. These are completely different concepts. However, for beginning readers, here are a few main points:.

Let's start with Tor: Firstly, it is strongly tied to the root servers of the office, to which the initial call is made to build a network picture. In I2P, these are the resids explicitly indicated in the code, which you can change to your own, or simply use ready-made address books, based on which the router will continue to work, completely bypassing the starting nodes. Secondly, according to competent users, Tor was originally and still belongs to the NSA, so there is no need to create illusions about it. Thirdly, Tor has a simpler tunnel architecture and fewer configuration options. Fourthly, Tor initially assumes proxying to the regular Internet, and in I2P this is only possible with additional configuration of the corresponding nodes and tunnels to them. In terms of mood, this point can be attributed to the disadvantages of I2P, but we disagree.

About Yggdrasil and similar mesh networks: such developments focus on ease of deployment, data transfer speed and self-organization. Traffic inside Yggdrasil is not artificially confused; the network has a simple and intuitive design. Users have strong bidirectional encrypted tunnels, and the shorter the better. As you can see, I2P has very little in common with Tor, and even less with common mesh networks. Except that I2P can work freely via Yggdrasil (support in i2pd from version 2.36.0). Through Thor too, by the way. That's probably all.

Afterword

Latest on the topic of I2P and hidden networks in general: is it ethical? The established public opinion is that any attempts at anonymization are regarded as criminal intent. For example, on hidden networks people can post things that would be blocked on a censored network. This of course infuriates the censors. Let’s not keep silent about the crime that can find refuge in I2P, all this is obvious. But what do I2P developers, who may also have families, children and a desire for justice, think about this, and what do most cryptoanarchists think? In short: a kitchen knife can cut bread, or it can cause harm, but due to the potential for abuse, kitchen knives are not prohibited. It’s the same here: you can’t fight privacy technologies under the pretext of fighting crime, since the most common crime today is a violation of civil rights and freedoms: total control and sale of personal data.

If you were still fascinated by “netstalking”, i.e. a romantic exploration of the contents of hidden networks, we encourage you to go further - to study the mechanics of these networks and contribute to their development. The “darknet” (or “deep web”) is not inherently something exotic; this is a modern set of necessary tools for the free dissemination of information and personal communication between people without artificial barriers.

The text of the article and illustrations are adapted from the sources of the video about I2P: in Russian And English. Material in PDF format is available on i2pd.website.